1. Field of the Invention
This invention relates generally to designing systems for digital signal processing and the like. More specifically, the present invention relates to estimating power consumption of a proposed electronic design based on a system level representation of the proposed electronic design early in the design process. The present invention can be used in connection with programmable or otherwise configurable devices, including programmable logic devices.
2. Description of Related Art
Electronic design automation (EDA) includes computer-based tools and/or processes that provide designers with automated tools for designing and verifying a user's custom circuit designs, such as integrated circuit or printed circuit board designs. EDA is used for creating, analyzing and editing a proposed electronic design for purposes of simulation, prototyping, execution and/or computing. EDA technology can also be used to develop systems that will use one or more user-designed subsystems and/or components. The end result of EDA is often a modified and enhanced design that is an improvement over the original design.
System design involves the creation, development and refining of electronic designs such as channels and other structures for implementation in electronic devices such as programmable logic devices (PLDs) and other programmable devices. System characteristics such as noise immunity, error recovery, etc. are evaluated using simulation and complex mathematical analysis software. However, later stages of the process require time and resource commitments that can be substantial. In response to this, some earlier design processes have provided designers with the ability to obtain information concerning area and speed of a proposed design.
However, current design flows for DSP intensive algorithms require near completion of the design flow prior to estimating power consumption of a proposed design. Understanding a design's static and dynamic power usage is critical to appropriate implementation of the design. This includes situations in which the design will be implemented in a programmable device, such as a programmable logic device (or PLD).
For example, in designing a filter for implementation in a programmable device, noise immunity characteristics and other information are needed by a designer, who has a choice of filters that vary as to depth and architecture and that have different costs, area usage implications, power consumption implications, etc. associated with the filter's performance. Using current design techniques, designers only optimize the filter relative to a performance vector. However, in the end, the designer may find that the filter cannot be implemented due to a system characteristic that the designer did not have at the system level phase of the filter's design. Because each alternative design must go through a complete design cycle (including development for and implementation and testing in hardware), the time and resources required for thorough consideration of all options can be prohibitive. The unavailability of system characteristic information thus restricts the different design strategies that can be explored, including, in the filter example, non-filter possibilities (such as forward error correction). Another example of a design situation in which options are limited is the evaluation of channel strategies for multi-channel implementations (such as whether to use parallel processing structures or time-division multiplexing or a hybrid of both).
The design process can be broken down into several domains (or phases), including a system level design domain/phase, a logic/DSP design domain/phase, a hardware level design domain/phase and a software level design domain/phase. In the system level phase, involving design entry and analysis, tools such as Simulink (an interactive environment for modeling, simulating and prototyping dynamic systems) and Matlab (an algorithm compiler), both of which are available from Mathworks, Inc. of Natick, Mass., and DSP Builder, from Altera Corporation of San Jose, Calif., can be used. Altera's DSP Builder integrates both high-level algorithm and hardware description language (HDL) development tools by combining the algorithm development, simulation, and verification capabilities of Matlab and Simulink system-level design tools with VHDL synthesis, simulation and Altera development tools. A designer using DSP Builder, which is based on Simulink, typically works from a Simulink representation to a VHDL representation to a bitstream representation. An algorithm usually is designed using hardware information such as bit-width and available hardware resources (for example, a pre-existing DSP block in the target hardware, other pre-set modules and functions, the presence of phase lock loop circuitry, the presence of embedded memory blocks, the structure and layout of logic elements, etc.).
Hardware testing can include downloading the design into the hardware platform and measuring the power consumption in the hardware. The system level design is compiled and evaluated in the logic/DSP and hardware design domains, including (for example) the following steps:                Translation to an RTL representation (for example, using SignalCompiler from Altera);        RTL analysis and synthesis (for example, using Quartus II from Altera—this step returns the estimated device area used by the design);        Fitting (again, for example, using Quartus II), which is typically the most time consuming step;        Timing analysis (again, for example, using Quartus II), which returns all the worst case timing information of the design; and        Power analysis (again, for example, using Quartus II), which returns estimated power consumption.        
If the estimated power consumption of a system design is over a required maximum value (or otherwise fails to meet some power constraint or requirement), designers must go back to the system level design domain.
Thus, when considering an algorithm developed as a proposed electronic design, designers have been able to include system level tool analysis hardware information such as data-path bit width and clock domain availability. Consideration of this hardware information in a system level tool has been critical in reducing the development cycle of a design under consideration. Unfortunately, as noted above, not all hardware implementation information has been available in system level tools. Power consumption requirements can drastically change the shape and nature of an algorithm (for example, by affecting decisions as to hardware-software co-partitioning, time division multiplexing, parallelism or over-sampling to determine optimal bandwidth frequency). However, tools for power consumption evaluation in DSP systems have only been available well into the hardware design phase. Currently, system level DSP algorithm developers have no tools that can help them estimate the static and dynamic power consumption of a proposed design under development prior to near completion of the entire design process.
As a specific example, one power consumption estimation development tool is the Power Gage tool used in connection with Altera's Quartus II design software. Power Gage provides power consumption information to a designer after a gate level representation of a system has been developed, usually in the logic/DSP design phase of the design process. FIG. 1 is a flow and schematic illustration of a specific prior art process similar to the Power Gage tool used in developing a digital signal processing (DSP) device or design in chronological sequence (time is denoted by the arrow at the bottom of FIG. 1). Typically, at least two different individuals or groups of people work on a design. First, one or more system designers are responsible for creating a system level design conceptually and in a written specification. Logic/DSP designers, a different group of individuals, then develop one or more hardware implementations of the design, using appropriate hardware (for example, a PLD).
More specifically, as seen in FIG. 1, in the system level phase of development at 110, an algorithmic representation of a design is developed at 112. This algorithm representation may be a flow diagram or other similar graphical and/or conceptual representation of the functionality or functionalities of the intended design. In this prior design process, a system level design based on the algorithmic representation is then created at 114. System level designers typically use C++, M and Simulink languages for their designs (though they may occasionally use VHDL and/or Verilog for system partitioning). Finally, a specification is written at 118. This ends the system level design phase of the process.
At this point, the logic/DSP design phase 120 begins. A written code representation of the design is generated at 122 (for example, an RTL code). Thereafter, a code simulation can be run at 123, followed by logic synthesis at 124, gate level simulation at 125 and place and route evaluation at 126. Throughout these steps, testing may be done. Finally, when these prior steps of the logic/DSP design phase are completed, a power estimation is done at 128.
The hardware design phase 130 of the process commences at approximately the same time as the logic/DSP phase 120. Initially, schematics are developed at 132, followed by development of a board layout at 134 and board manufacturing or creation at 136. The hardware designers typically use VHDL and Verilog languages for their designs.
The software design phase 140 can begin at about the same time as the development of the board layout. This software design phase 140 can include software development and debugging at 142 followed by software integration at 144.
Various readings and estimates can be taken and made during this prior process. As seen in FIG. 1, a first area estimation can be performed after the place and route evaluation at 126. In addition, a first power estimate is made at 128. These estimates can be provided to a decision maker 155 to determine whether the estimated power consumption is too high and/or whether the estimated area usage is too high. If neither is too high, no changes to the system are required at 156. This is highly unusual with a first or early version of a proposed design. When either or both of the estimates is too high, changes must be made to the proposed design at 157. As seen in FIG. 1, the decision maker 155 also may take into account power levels measured after the board manufacture step at 136 in the hardware design phase 130. The changes to the proposed design can include going back to the algorithm development step at 112 and the written specification at 118 in the system level design phase 110. Moreover, changes may be made to the proposed schematics at 132.
As will be appreciated by those skilled in the art, revisiting algorithm development, specification writing and schematic design steps in this process represents a costly and time consuming step backward in the design process, as well as a sacrifice of resources expended in getting to this point. Substantial time, money and other resources likely have been invested in getting to the point where power and area estimates and measured power levels can be used to determine the feasibility and/or desirability of a proposed design.
Systems, methods, products and techniques that permit system level power consumption estimation for use in DSP design would allow early, system level estimation so that different ideas can be compared to power consumption requirements and considerations, thus saving time and effort that would otherwise go into undesirable or unworkable algorithms and/or designs, would represent a significant advancement in the art. Moreover, providing designers with information and requirements to estimate needs and/or costs at the system level phase of electronic design will provide those designers with better estimation tools to reduce design time and cost and would likewise constitute a significant advancement in the art.